<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Discarded paperwork',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2018/12/27.jpg" alt="Colourful carrots" class="framed-centred-image" width="649" height="480"/>
<section id="dreams">
	<h2>Dream journal</h2>
	<p>
		I dreamed my mother threw out a bunch of papers I was still using, so I had to dig them back out of the recycling and resort them.
		In particular, she ripped up the to-do list on my bulletin board and threw that out.
	</p>
</section>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion post for the day:
	</p>
	<blockquote>
		<h3>Part 0: Lazy evaluation</h3>
		<p>
			Lazy evaluation is the act of not evaluating the entire expression, but instead evaluating only the parts that lead to the result.
			It&apos;s a necessary component of functional programming, which doesn&apos;t involve variable assignment.
			Because there are no variable assignments, the output of one function will need to be directly fed as input to another.
			There&apos;s also the problem of branching.
			With all statements strung together as compound statements, there&apos;s no chance to check the value of a sub-expression before using that output in the next part of the expression.
			As a result, the effect of both options in the conditional are included in the expression regardless of the yet-to-be-found value they&apos;ll operate on.
			One of those branches will be irrelevant, yet it&apos;ll still be evaluated.
			Or rather, it would be evaluated with greedy evaluation, which is what imperative programming languages use.
			The branch not used may try to perform invalid operations on the value, which would cause the entire expression to fail.
		</p>
		<p>
			Lazy evaluation caused the unused branch to simply not evaluate (Ben-Ari, 2006).
			It&apos;s probably called &quot;lazy&quot; because the computer just skips over the work it can get out of doing, but it&apos;s not lazy in the traditional sense because that work wouldn&apos;t&apos;ve accomplished anything of value anyway.
			Is it lazy to skip watering your plants right after it rained?
			Not really.
			The plants already got enough water that day without your help.
			Watering them would be wasted effort on your part, and wasted water.
			It would be foolish for you to water your plants right after it rained.
		</p>
		<p>
			More importantly though, lazy evaluation is vital when conditional branches operate on values that don&apos;t make sense outside the context of that branch.
			For example, You might have a branch that takes the square root of a value, but that branch only applies when the value is greater than or equal to zero.
			With greedy evaluation, the computer would try to figure out the square root even for negative numbers, which have no square root.
			With greedy evaluation, your entire expression will fail for negative numbers; your conditional won&apos;t protect you.
			Alternatively, you might try to divide by n for non-zero values of n. Again, such a conditional won&apos;t protect you if you&apos;re using greedy evaluation.
			The machine will try to divide by zero and your expression will fail.
			With lazy evaluation, bot of the above conditionals would protect you from error, as the branch that uses the value inappropriately simply won&apos;t be evaluated when such use would be considered inappropriate.
		</p>
		<h3>Part 1: Higher-order functions and currying</h3>
		<p>
			Higher-order functions are simply functions that take other functions as arguments (Ben-Ari, 2006).
			The book presents them as if they&apos;re specific to functional programming, but they really aren&apos;t.
			In the Lua environment I frequently work in, many of the $a[API] calls I have to make require functions be passed in as arguments.
			Lua, in general, has no problem with functions being passed as arguments, because everything in Lua, including the functions themselves, are just things stored in variables.
			Many object-oriented languages behave similarly.
			You can pass functions as arguments in Python and JavaScript too, for example.
			In $a[PHP], we can&apos;t exactly pass functions themselves as arguments, but there&apos;s the concept of a callable value, which in almost every case maps back to some functions that can get called.
			While functions aren&apos;t technically being passed as arguments in $a[PHP], semantically, they are.
			In Standard ML, functions have their own types based on their inputs and outputs.
			As a result, only functions with specific input and output types need be accepted by a function that needs another function as input.
		</p>
		<p>
			Currying is an odd concept used to deal with a limitation in functional programming languages.
			For whatever reason, functional programming language functions are unable to take multiple inputs.
			One method of dealing with this is to create structures and pass them in.
			For example, instead of passing in two integers, pass in one list of integers that happens to contain two integers (Ben-Ari, 2006).
			Another method is currying.
			A curried function takes one input and outputs another function, which is then applied to the next input (Ben-Ari, 2006).
			It looks like one function is taking two (or more) inputs, but instead, two (or more) functions are taking one input each in a chain.
			All but the final function output a function as output, so this function can be applied to the next input.
		</p>
		<p>
			In a way, you could say that higher-order functions and currying are opposite concepts.
			One takes a function as input, while the other provides a function as output.
			I see no reason either why they couldn&apos;t be done together.
			For example, a function might take another function as input, and provide a new function as output for processing the next input.
		</p>
		<div class="APA_references">
			<h3>References:</h3>
			<p>
				Ben-Ari, M. (2006). Understanding Programming Languages. Retrieved from <a href="https://my.uopeople.edu/pluginfile.php/356896/mod_page/content/30/understanding_programming_languages.pdf"><code>https://my.uopeople.edu/pluginfile.php/356896/mod_page/content/30/understanding_programming_languages.pdf</code></a>
			</p>
		</div>
	</blockquote>
</section>
END
);
